perf(repsel): element-shape loop clone serves the element-binding form through function boundaries (#7766) - #7778

Closes #7766.

The verified framing (the issue asked for this first)

The issue's mechanism 1 said the clone "is admitted but its body does not specialize element field reads" and asked that framing to be verified before building on it. Measured on current main (423bb44):

• The direct spelling is already served. s += ps[i].x + ps[i].y through a typed P[] parameter gets a versioned clone whose deref block cond_brs INTO the fast preheader (the perf(repsel): the element-shape loop clone fires on arr.length and aliased element types (#7480) #7701 entry test), with offset loads and no calls in the fast body. Runtime confirms: 0.10s vs node 0.07s on 200k×200 (dev profile). The by-name/guard/coerce calls the issue counted in (A)'s IR belong to the slow clone — mandatory fallback IR, dead at runtime for an honest caller.
• The binding spelling was the real gap. { const r = ps[i]; s += r.x + r.y } — and for (const p of ps), which desugars to exactly that shape — got no clone at all: 2.2× and 7.8× slower than the direct spelling respectively. Two independent causes:
  1. the matcher admitted only a single-statement accumulator body, and
  2. the for-of desugar mints its counter as Number(0.0), which collect_integer_let_ids does not seed, so the desugared counter never joined integer_locals, never got a canonical i32 slot, and every i32-counter loop optimization silently declined the for…of spelling of loops it served in indexed form.

Mechanism decision (all three evaluated)

1. Extend the element-shape guarded clone — chosen. The guard establishes the fact at runtime (js_array_ensure_element_shape verifies every element's class; the declared type only names the class id to check against), so it is sound for parameters by construction — exactly the "establish, don't assume" bar the issue sets. With the framing corrected, the remaining work was matcher coverage, not read specialization, which makes this by far the smallest correct change (~120 lines, no new ABI, one clone per loop as today).

2. Clone-and-route at the call site — needs per-signature callee clones (code size), call-site proof plumbing across modules, and serves only calls whose arguments already carry proofs — which #7170 measured as rare in dependency JS (91.6% of its rule-1 population sits in closures where no proof exists). A runtime guard is still needed for unproven callers, i.e. mechanism 1 is a prerequisite of 2, not an alternative.

3. Entry guard + specialized body — pays the guard on every call even when the loop is cold, duplicates the whole function body instead of one loop, and the guard's O(n) first-scan can be wasted work if the loop is never reached. The loop-preheader placement already implemented is strictly better positioned.

What this PR changes

1. Matcher (stmt/element_shape_loop.rs): admits an optional leading const r = arr[counter] element binding whose every use is a tracked r.field read. The binding's source array participates in the one-array-per-loop rule, and any other use of r — bare reference, mutable binding, non-counter index, second array — declines (each shape has a red test).
2. Lowering: the fast clone skips the binding's Let entirely — lowering it would emit the element-read tier's calls, fail the call-free scan, and silently delete the clone (fix(gc): restore evacuation at precise safepoints — the pacing half of #7682 #7690's failure shape). r.field reads are answered by the loop fact (element_binding_local on ElementShapeLoopFact); the slow clone keeps the full body, so the side-exit protocol (re-execute the current iteration, nothing committed) is unchanged.
3. for-of desugar (both emission sites: lower/stmt_loops.rs module-init, lower_decl/body_stmt.rs function bodies): the minted counter init is Integer(0) instead of Number(0.0) — the literal kind the integer-local collector seeds on, and the same shape a user-written let i = 0 produces. (for-in deliberately untouched.)
4. --opt-report: the clone records a Ptr<Shape> selection — and per-read consumption — when and only when the deref block branches into the fast clone (an emitted-but-deleted clone records nothing: a gate must assert its subject was live).

Acceptance criteria, measured

1. ✅ --opt-report on the binding case now prints Ptr<Shape> 1 selected … 1 of those selections were CONSUMED, naming the binding local; the fast clone emits no js_object_get_field_by_name_f64, no js_typed_feedback_class_field_get_guard, no js_number_coerce (asserted by IR census with the perf(repsel): the element-shape loop clone fires on arr.length and aliased element types (#7480) #7701 entered-not-just-emitted test).
2. ✅ Case (B) untouched (static ptr_shape_elements route unchanged; full element_shape suite green — 28 tests).
3. ✅ Soundness is tested, not argued: test-files/test_gap_repsel_element_shape_param_binding.ts runs mixed arrays, a subclass with extra fields, same-shape plain literals, a hole, mid-loop mutation, growth between calls, and a fake array-like through the parameter boundary in both spellings — byte-identical to node 26.5.1 (the pinned oracle).
4. ⏳ Corpus rule-1 bucket: measured on the repsel: dependency JS is walled by rule 1 (unbound allocations), not containment — 506 of 746 candidates #7152/repsel: rule-1 provenance for unbound allocations — the 506 are 96% record literals, and Perry's own CJS IIFE is the wall (#7152 follow-up) #7170 corpus with both arms; numbers in the first comment. Honest expectation set by repsel: rule-1 provenance for unbound allocations — the 506 are 96% record literals, and Perry's own CJS IIFE is the wall (#7152 follow-up) #7170's own tier data: the corpus bucket is dominated by unbound-allocation sites (40.4% nested-literal components, 16.9% opaque-runtime-callee arguments) that no read-side mechanism can serve; this PR serves the T3 (parameter-shape) slice's in-loop reads. The first-party half — the case the issue was filed on — is what moves wholesale.
5. ⏳ Protected floors: interleaved best-of-5 on the pinned mini, outputs byte-verified against node before timing; table in the first comment.

Perf (probes, dev profile, 200k elements × 200 passes, local M1)

Known-unrelated red

large_object_barriers::large_local_array_push_inbounds_store_emits_precise_slot_barrier fails identically on clean main @ 423bb44 (verified in a pristine worktree); the fixture is hand-built HIR with no for…of and no element-shape loop, so it is structurally unreachable by this diff. Integration suites don't run per-PR (#5960), which is how it sits red on main.

Heads-up

#7771 (wt-7771, in flight) specializes bare a[i] fetches inside the same clone and touches the same three files — whichever lands second will need a small rebase.

Summary by CodeRabbit

• Performance

  • Improved optimization of array-element loops passed through function parameters.
  • Added support for more array shapes and safer handling of mixed, sparse, mutated, and array-like inputs.
  • Improved integer loop-counter recognition.

• Bug Fixes

  • Prevented optimization when indexed bindings cannot be safely verified.
  • Preserved expected error behavior for unsupported array contents.

• Tests

  • Added extensive regression coverage for optimized and fallback execution paths.